Pending latest changes from Widehopf: Dev - #5

immediately handle messages from modesbeast, don't wait for next loop
iteration

both these changes aren't really fixing anything but it's better this
way

issue was introduced when changing stuff around adding macOS compatibility

… at the expense of IOPS

…tency

this list is used to determine which non-position data to accept for a
certain aircraft
it is also used to determine the number of active receiver for a certain
plane

no reason to use more than certain amount of threads

Three things kept 'make benchmarks' from working:

- it ran ./convert_benchmark while the binary is built as
  oneoff/convert_benchmark, so the target failed even once the object
  compiled;
- the link rule still listed only convert.o and util.o with -lm. util.o has
  since grown dependencies on threadpool.o, zlib and zstd, so the link fails
  with a page of undefined symbols. Use $(LDFLAGS) $(LIBS) and add
  threadpool.o plus $(COMPAT);
- 'make clean' removed ./convert_benchmark and left oneoff/*.o and the real
  binary behind.

* fix(docker): retry aircraft.csv.gz fetch on transient HTTP errors

Hit repeated "ERROR 404: Not Found" fetching aircraft.csv.gz from
github.com/.../raw/csv/... in a downstream fork's CI, several times in a
row a few minutes apart, while this repo's own scheduled build succeeded
earlier the same day on presumably the same command — looks like GitHub
throttling/blocking unauthenticated raw fetches from GitHub-hosted-runner
IP ranges rather than a real 404. wget does not retry on HTTP 404 by
default regardless of --tries, so a single hit fails the whole build.
--retry-on-http-error forces a retry even on 404.

* fix(docker): fetch aircraft.csv.gz from raw.githubusercontent.com directly

github.com/wiedehopf/tar1090-db/raw/csv/aircraft.csv.gz (the legacy
redirector) is returning a hard 404 right now, reproduced both from CI and
from a plain machine — not rate limiting, the redirect itself is broken.
raw.githubusercontent.com/wiedehopf/tar1090-db/csv/aircraft.csv.gz (what it
used to redirect to) serves the same file directly; verified via the
GitHub contents API that the file itself is intact (8328079 bytes).

---------

Co-authored-by: Riccardo Sabatti <riccardo@codeflow.it>

retry-wait defaults to 10 so remove unnecessary parameter

add lowered timeout

reduce number of max retries

180 / 256 is evaluated as integer division and yields 0, so every
decoded MRAR wind direction was 0 degrees. Use a float constant
(LSB = 180/256 degrees).

…e DF20 altitude (#149)

Implements the check left as a comment ("Should check IAS vs Mach at
given altitude"). For DF20 replies the pressure altitude is in the
message, so CAS can be computed from Mach through the ISA pressure
ratio and compared with the reported IAS; a mismatch above 25 kt costs
12 points. DF21 replies (no altitude) are unaffected.

Sanity values: M0.78 @ 35000 ft -> 264 kt; M0.45 @ 10000 ft -> 249 kt;
M0.22 @ 3000 ft -> 138 kt.

TAS (BDS 5,0) and Mach (BDS 6,0) arrive in different Comm-B replies and
each field stays valid for up to 35 s independently. Consumers that
derive outside air temperature from the TAS/Mach pair (as readsb itself
does in calc_temp, but only for Mach >= 0.395) have no way to tell how
far apart the two samples are. On a decelerating aircraft on final a
5 s mismatch is ~5 kt of TAS, i.e. ~20 K of error.

Two optional fields, seconds with one decimal, printed next to tas/mach.

will possibly add more age_fields to this flag in the future

calc_wind rejects wind speeds above 250 kt as unrealistic, but calc_temp
publishes whatever the TAS / Mach pair gives. When one of the two comes
from a garbage or misclassified Comm-B register (a BDS 6,0 that passed
the score checks via DF21, where the IAS / Mach altitude check cannot
run), oat and tat go to absurd values and stay in aircraft.json for the
usual 60 s.

Seen on a live feed at SKCL: TAS 242 kt with Mach 0.760 at 8,300 ft
(IAS 234) gave oat -206 C; two aircraft produced 24 samples between
-205 and -250 C in one day while the correct pairs around them gave
-1 to +20 C.

Reject the calculation when oat is outside -100 .. +60 C, the same way
calc_wind does for wind speed. The thresholds are generous: the coldest
air aircraft fly through (tropical tropopause) is around -85 C and the
hottest surface air around +55 C.

decodeCommB rejects the message if mm->DR != 0 || mm->UM != 0, but
decodeModesMessage calls decodeCommB (MB field) before it decodes UM,
and the message struct is zeroed beforehand, so mm->UM is always 0 at
that point and the UM condition has never had any effect. Remove it
and say so in the comment; DR is decoded earlier and keeps working.

No behaviour change. Measured on a live feed at SKCL (30 min, 5513
DF20/21): UM != 0 in 4 replies (0.1 %), none of them a plausible
BDS 5,0/6,0; DR != 0 in 1.0 %. Making the UM check effective instead
would start rejecting Comm-B replies carrying a multisite interrogator
identifier (IIS), which some SSR networks use, so I did not do that.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011BqHQDHRKNRuJHR4oQB55L

track_age and track_max_age are both int64_t, so
(1.0f - track_age / track_max_age) is 1.0 for every track younger than
track_max_age (5 s), which is the only case where the branch runs. The
track bonus (or penalty, for positions against the track) was meant to
fade out with the age of the track and never did. Cast to float.

Factor before -> after: 0.5 s 1.00 -> 0.90, 1 s 1.00 -> 0.80,
2.5 s 1.00 -> 0.50, 4.9 s 1.00 -> 0.02.

A/B on the same live Beast feed (single RTL-SDR receiver at SKCL, 7 h,
232754 global and 1008 local CPR decodes): no speed_check rejections in
either build, all cpr counters identical. The change only matters when
a position is near the speed limit, which this feed did not exercise.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011BqHQDHRKNRuJHR4oQB55L

fixes: #156

some transponders seem to send wind_valid despite it not being valid
i'm not aware of comm_b actually providing wind speeds anywhere in the
world properly, so this shouldn't hurt and remove some bad data

allow for calculation to occur more often per plane

fix tas not being updated for tas < ias

fixes: #157

…hex codes

- actions/checkout v3 -> v7 (v3 runs on the deprecated Node16 runtime)
- docker/metadata-action v4 -> v6
- docker/setup-qemu-action v2 -> v4
- docker/setup-buildx-action v2 -> v4
- docker/login-action v2 -> v4
- docker/build-push-action v4 -> v7
- .github/dependabot.yml: weekly github-actions updates so the
  workflow (the repo's only CI) does not fall behind again

No input renames: images/tags/labels, push, platforms, build-args
and outputs are unchanged.

- New .github/workflows/build.yaml: build + make test on
  ubuntu-22.04/24.04 x gcc/clang, plus an RTLSDR=yes build.
  Until now the only CI was the Docker image build; the C code
  was never compiled or tested on pull requests.
- Makefile: the crctest target depended on cprtests and ran
  ./cprtests a second time, so make test executed the CPR suite
  twice and never built or ran crctests (crc.c CRCDEBUG harness).
  It now depends on crctests and runs ./crctests 1 2 (the
  empirically clean configuration noted in crc.c).
- .gitignore: cprtests/crctests binaries are produced by make test
  but were not ignored.

Verified locally on Ubuntu 22.04 (gcc 11.4, clang 14, -Werror):
make -j4 && make test passes for gcc/clang with RTLSDR=no and
RTLSDR=yes.